QRZ! Ham Radio 4/QRZ Ham Radio Callsign Database - Volume 4.iso/digests/digital/940101.txt

Internet Message Format | 1994-11-13 | 20KB

Date: Thu,  7 Apr 94 04:30:09 PDT
From: Ham-Digital Mailing List and Newsgroup <[e-mail]>
Errors-To: [e-mail]
Reply-To: [e-mail]
Precedence: Bulk
Subject: Ham-Digital Digest V94 #101
To: Ham-Digital


Ham-Digital Digest          Thu,  7 Apr 94       Volume 94 : Issue  101

Today's Topics:
                        Baycom TCP/IP Software
                    FCC Packet Message Forwarding
                     MFJ 1270C TNC and Host Mode
           spread-spectrum links hooking libraries in CA..
                     Televideo 925 terminal setup
                      X1-J and DRSI DPK-2 TNC's

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the Ham-Digital Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/ham-digital".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: 6 Apr 94 20:19:27 GMT
From: [e-mail]
Subject: Baycom TCP/IP Software
To: [e-mail]

>Is there a driver available for TCP/IP on the Baycom software and modem?

There is a file AX25DRV.ZIP available which contains a driver and
instructions.  It should be on ucsd.edu somewhere in
/hamradio/packet/tcpip and is also available on the TAPR
fileserver.  Send a message to [e-mail] with the
lines:

get /pub/packet/ax25drv.zip

and it will be send uuencoded.

------------------------------

Date: 7 Apr 1994 05:11:17 GMT
From: ihnp4.ucsd.edu!swrinde!gatech!udel!news.sprintlink.net!connected.com!krel.iea.com!comtch![e-mail]
Subject: FCC Packet Message Forwarding
To: [e-mail]

Well it's final.... Here is the latest rule from the FCC.....








Report No. DC-2582         ACTION IN DOCKET CASE              April 4, 1994


           COMMISSION AMENDS RULES CONCERNING MESSAGE FORWARDING
                      SYSTEMS IN THE AMATEUR SERVICE
                           (PR DOCKET NO. 93-85)

     The FCC has relaxed the amateur service rules to enable
contemporary message forwarding systems to operate at hundreds of
characters per second while retaining safeguards to prevent misuse.

     A message forwarding system is a group of amateur stations
participating in a voluntary, cooperative, interactive arrangement
where communications from the control operator of an originating
station are transmitted to one or more destination stations via
forwarding stations, which may or may not be automatically
controlled.

     Currently, the control operator of each station is held
individually accountable for each message retransmitted, resulting
in unnecessary content review and delays.  The American Relay
League, Inc. (League) stated that the obligation of the control
operator of the first forwarding station should be the
establishment of the identity of the station originating the
message.  Only when this is not done should these control operators
be held accountable for improper message content.  Also, there are
currently no central supervisory authority in an ad hoc amateur
service digital network, making these unsupervised systems easy
targets for misuse by uncooperative operators and non-licensees.
Moreover, the Commission said that it could be difficult to
establish after the fact that a particular VHF station originated
a fleeting high speed digital transmission.  For these reasons, the
Commission said there must be on-going oversight of the system and
the control operators of the first forwarding stations are in the
best position to provide such oversight.

     Therefore, the Commission will hold accountable only the
licensees of the station originating a message and the license of
the first station forwarding a message in a high speed message
forwarding system.  The licensee of the first forwarding station
must either authenticate the identify of the station from which it
accepts communications on behalf of the system, or accept
accountability for the content of the message.


                                  (over)


                                    -2-

     The Commission also clarified that the station that receives
a communication directly from the originating station and
introduces it into the message forwarding system is the first
forwarding station.

     The League and the Colorado Council of Amateur Radio Clubs
suggested that the Commission substitute the word "simultaneously"
for "instantaneously" in the redefinition of a repeater.  The
Commission concurred and adopted this modification.

     The Commission believes that these rule changes will enable
contemporary high speed message forwarding systems to operate as
their designers intended, while retaining the minimum safeguards
necessary to prevent misuse.

     Action by the Commission March 30, 1994, by Report and Order
(FCC 94-76).  Chairman Hundt, Commissioners Quello and Barrett.


                                   -FCC-

     News Media contact: Patricia A. Chew at [phone].
     Private Radio Bureau contact: William T. Cross at (202) 632-
4964.


--
|<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
| Chuck Vyverberg                   | Internet: [e-mail]       |
|                                   | Packet : WB7NNF@WB7NNF.#EWA.USA.NOAM  |
|                                   |                                       |
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

------------------------------

Date: 6 Apr 94 20:26:42 GMT
From: [e-mail]
Subject: MFJ 1270C TNC and Host Mode
To: [e-mail]

>I've been looking through my TNC documentation, and the only reference I find
>to host mode mentions that documentation is available on diskette, but no
>command is given for putting the TNC into host mode.
>
>Can anyone help?

There is a disk containing discriptions of the host mode and a
primative program to use it available from TAPR.  Also a file with
documentation up to TAPR version 1.1.8a firmware, which has the
pertinent commands (with much other valuable TNC information).  Send a
message to [e-mail] with the following lines in the
body of the message:

get /pub/packet/tnc2host.zip
get /pub/packet/tnc2doc.zip
quit

The files will be sent to you uuencoded.

------------------
Bob Nielsen, W6SWE              Internet: [e-mail]
Tucson, AZ                      AMPRnet:  [e-mail]
[44.124.12.16]                  AX.25:    [e-mail]

------------------------------

Date: Wed, 6 Apr 1994 15:08:26 GMT
From: ihnp4.ucsd.edu!usc!howland.reston.ans.net!news.ans.net!paperboy.amoco.com!apctrc!msc.edu!mr.net!idss.nwa.com!csinc![e-mail]
Subject: spread-spectrum links hooking libraries in CA..
To: [e-mail]

I remember reading about a project some of the guys on here did a while
back to hook libraries in some part of California to the Internet using
part 15 spread-spectrum equipment.  Are those guys still around ?  If so,
I have a couple questions for you and would like to discuss that project...
Could you email me ?

Thanks.

Chris

--
Chris Elmquist, N0JCF        voice:    [phone]
[e-mail]        fax:    [phone]

------------------------------

Date: Thu, 7 Apr 1994 02:48:33 GMT
From: ihnp4.ucsd.edu!swrinde!cs.utexas.edu!howland.reston.ans.net!europa.eng.gtefsd.com!news.umbc.edu!eff!news.kei.com!ub!acsu.buffalo.edu![e-mail]
Subject: Televideo 925 terminal setup
To: [e-mail]

Anyone have the manual for a Televideo 925 terminal?  I have purchased one
second hand, and would appreciate any information about the two banks of DIP
switches at the back of the terminal.  One is labelled baud (but no explanation
of what switches select which speed).   The other is labelled function.  I
believe that there is also a third bank of switches inside the unit.  Any help
would be appreciated.

Thanks,

John Welch
KA2VGV

------------------------------

Date: 7 Apr 94 06:09:08 GMT
From: [e-mail]
Subject: X1-J and DRSI DPK-2 TNC's
To: [e-mail]

I'm planning to install a X1-J rom in to a DRSI DPK-2.  Is there anything
I should look out for before doing the bank switching mod???

Oh and also is there a sourceon info on wiring a TNc w/ a 9600 bd modem
to a Motorola Maxtor UHF radio.

Thanks

Stephen sharp
IBM, Micro Electronics Div.
Burlington, VT                         Internet ID: [e-mail]

------------------------------

Date: 6 Apr 1994 22:10:39 GMT
From: news.mentorg.com!hpbab33.mentorg.com!wv.mentorg.com![e-mail]
To: [e-mail]

References <[e-mail]>, <2nphhd$[e-mail]>, <2nqhsn$[e-mail]>om
Reply-To : [e-mail]
Subject : Re: [REPOST] The # in PBBS addresses....

In article <2nqhsn$[e-mail]>, [e-mail] (Brian Kantor) writes:
|> In article <2nphhd$[e-mail]> [e-mail] writes:
|> >You are perhaps talking about the internet, which chose to ignore
|> >the existing use of NA in one of it's connected networks?
|>
|> Oh jeez, Hank, stop making things up.  The AMPR.ORG domain has never used
|> the ham bbs hierarchical routing/addressing scheme to name hosts.

We were not discussing host names.  We were discussing email addresses.

Please do not confuse a host name with an email address, this is one of the
worst mistakes an email system designer might make.

But since you brought up the topic, why would AMPR.ORG *not* choose some
sort of rational subdomain naming convention for host names?

Perhaps the fact that they didn't, and that they consistently confuse email
addresses with host names is why it is impossible to move email from
one tcp/ip system within .ampr.org to another without making use of those
"other" (BBS network) email addresses?

But now back to our scheduled discussion of email addresses.

|> With some exceptions, the namespace of the AMPR.ORG domain consists
|> solely of callsigns within the domain.  Names are not routes, routes
|> are not names, and mixing them up is one of the worst possible mistakes
|> a network architect could make.

Well gee Brian!  Glad you least understand the basics!
A name is not a route.
A route is not a location.
An address is none of the above.
Etc. etc.
So *WHY* do you persist in confusing them?
Repeat after me "A host name is not an email address."

|> That means that whilst you might see
|>     W0RLI.AMPR.ORG
|> or
|>     BBS.W0RLI.AMPR.ORG
|> you won't see
|>     W0RLI.#NNJ.NJ.USA.NOAM.AMPR.ORG
|> or the like

And why would I not see such things?
Why would we not use subdomains in our email addresses?
Why would we not put routing hints into our email addresses?
Why would we not identify our email address by it's internet domain name.

Why wait!  Look at my signature!
It has ".mentorg.com", which clearly is an internet domain name!
But wait ... there is something missing - the subdomains.
Why are they missing?  Because a router with address "mentorg.com"
will take care of translating the (missing) portion of my email
address once email addressed to the "mentorg.com" domain arrives
there.  Where is "there"?  Well, that depends on where your email
to me started ... "there" might be NJ or OR or Bracknell or Singapore.
At any one of these locations email destined for <x>.mentorg.com
is re-routed by adding the rest of the address.

So the rest of the world does not need to know about .hanko.mentorg.com,
nor about .hanko.moses.mentorg.com, nor about
hanko.moses40.moses.mentorg.com

We use ABBREVIATIONS and ALIASES for the actual addresses.

What does this have to do with the ham radio digital network?

In the ham radio digital network, we do not yet use aliases nor
abbreviations.  We specify the whole email address.

(Note for Brian: this is NOT "source routing" since we do not specify a
route, but specify an address).

Look again in my signature.  I show a ham radio digital network email
address. There is *no* "host name" in that address.  There are in fact two
hosts that may handle email addressed to my address: RLIMB:W0RLI-2 and
WLINN2:W0RLI-4.  These are the host addresses within the AX.25 network.
In the CLOVER network, that first host is named W0RLI. This is not
confusing to anyone, because the W0RLI name is only known in the CLOVER
network, and the RLIMB and WLINN2 names are only known in their respective
AX.25 networks.  If I had a tcp/ip system on air, it would have an ip address.

Most folks have no trouble distinguishing between the email address and the
host name.  It is not a complicated thing.  In fact it is very simple:
email destined for email addresses of the form ".OR.USA.NOAM" may be sent
to any of the hosts listed in the previous paragraph, and it will be
properly delivered.  Oh yes - email addresses of the form ".WA.USA.NOAM"
may also be sent to these hosts as well.  If you want email to reach me
personally you may send it addressed per my signature, and to any of those
same hosts.


Brian, now that you have again told us "Don't do it that way" would you please
oh please tell us "The right way to do it."

   ...  Hank

--

Hank Oredson @ Mentor Graphics
Internet     : [e-mail]
Amateur Radio: [e-mail]

------------------------------

Date: 6 Apr 94 23:17:20 GMT
From: dog.ee.lbl.gov!ihnp4.ucsd.edu!news.cerf.net!ccnet.com!ccnet.com![e-mail]
To: [e-mail]

References <2nph5e$[e-mail]>, <[e-mail]>, <2nuqbe$[e-mail]>
Subject : Re: NTS traffic on packet

Hank Oredson ([e-mail]) wrote:

: What would prevent duplicates or lost messages?
: How would you accomplish this?  Remember we don't have a "fixed
: configuration" network.  We don't have reliable paths.  We do have multiple

I don't understand. There are fixed routes in and out of any full service
bbs. The HF routes may seasonally change and require manual assistence.
What is going to happen if the BBS protocol is allowed to be the rule on
the DASH digital amateur super highway. It is my understanding that the
proposal for the 219 MHz 56kb DASH will require point to point auxiliary
operation. Will the bbs protocol work in this new arena?

: ways to get from point A to point B.  We don't have a protocol that
: addresses all the problems, and would *love* to have one.

: Any suggestions would be most welcome.

: I hope we will hear from the networking gurus on these topics.

: So far, we have heard from a couple of the networking gurus.
: Their message has been "You are doing it wrong."
: I presume they will follow up with "And here is how to do it right."

: ("just use tcp/ip" is not a reasonable answer.  We don't use it.)

Maybe the answer is to make the 219 MHz DASH a tcp/ip network and put the
bbs mail traffic into <envelopes> for safe transport across the network. I
would like to see some more discussion on the future implementation of
this new network.

Has anyone done any traffic analysis of bbs messages? Are the bulk of the
messages two or three hops? With the increase in network speed will the
message flow naturally increase? Will my bbs mail reading program be able
to keep up with the vast number of bulletins that will be arriving? I
realize that I will be reading at 1200 for quite some time ... maybe 9600
if the bbs operators will provide this service.

Sorry Hank, I am not a network guru, just your average packet user.

Bob


: --

: Hank Oredson @ Mentor Graphics
: Internet     : [e-mail]
: Amateur Radio: [e-mail]



--
     Bob Wilkins                     work    [e-mail]
 Berkeley, California                home    [e-mail]
     94701-0710                      play    n6fri@n6eeg.#nocal.ca.usa.noam

------------------------------

Date: 6 Apr 1994 17:09:02 GMT
From: news.mentorg.com!hpbab33.mentorg.com!wv.mentorg.com![e-mail]
To: [e-mail]

References <[e-mail]>, <2nph5e$[e-mail]>, <[e-mail]>g.c
Reply-To : [e-mail]
Subject : Re: NTS traffic on packet

In article <[e-mail]>, [e-mail] (Daniel T Senie) writes:
|> In article <2nph5e$[e-mail]> [e-mail] writes:
|> >In article <[e-mail]>, [e-mail] (Daniel T Senie) writes:
|> >|> In article <2nejic$[e-mail]> [e-mail] (Mike Stansberry) writes:
|> >|> >Jeffrey D. Angus ([e-mail]) wrote:
|> >
|> >|> I have lately seen traffic duplicated 2 or 3 times. One message I sent to
|> >|> my STM at the other end of the section got there 4 times. We have had
|> >|> a rash of multiple NTS deliveries.
|> >
|> >This is a very serious problem.
|> >
|> >There are many possible causes, but they all come down to poor operating
|> >practices by the sysops.  If the sysops had things set up reasonably,
|> >and made certain their systems were operating properly, then there would
|> >be no (zero, zilch, none) duplicated bulletins.
|> >
|> >Personal messages and NTS traffic are handled differently.
|> >Duplicates are allowed to occur, rather than lose an occasional message.
|> >However, these duplicates should be rare: 1 in 1000 perhaps.
|>
|> This raises some alarm bells with me. Networks need to either send or not
|> send messages. Protocols are designed to be able to be sure of such things.
|> Could you imagine if something like an international money transfer were
|> occasionally duplicated on the commercial networks? It sounds like the
|> protocols involved (in nthis case, the handling methods) may need some
|> review.

We are not talking "banking networks" here, we are talking about a network
rather similar to the internet.  Duplicates occur.  Such is life.
Any suggestions you have would be most welcome ...

|> Why is the software designed to allow even an occasional duplicate? Why
|> is there otherwise the possibility of a lost message?

What would prevent duplicates or lost messages?
How would you accomplish this?  Remember we don't have a "fixed
configuration" network.  We don't have reliable paths.  We do have multiple
ways to get from point A to point B.  We don't have a protocol that
addresses all the problems, and would *love* to have one.

Any suggestions would be most welcome.

I hope we will hear from the networking gurus on these topics.

So far, we have heard from a couple of the networking gurus.
Their message has been "You are doing it wrong."
I presume they will follow up with "And here is how to do it right."

("just use tcp/ip" is not a reasonable answer.  We don't use it.)

...

   ...  Hank

--

Hank Oredson @ Mentor Graphics
Internet     : [e-mail]
Amateur Radio: [e-mail]

------------------------------

End of Ham-Digital Digest V94 #101
******************************